The invention relates to an improved telecommunications protocol for networks having relatively long propagation times which enables more efficient communication. More specifically the present invention relates to the area of satellite communication protocols for a return satellite channel with special features to increase the efficiency of transmission.
Satellite networks may often be configured such that there are many very small aperture terminals (VSAT's) in communication with one Hub. Signals are sent from the hub to the VSAT's (and vice versa) via a communications satellite. Signals from the hub to the VSAT's are referred to as forward signals. Signals sent via a communications satellite from the VSAT's to the hubs are referred to as the reverse or return signals.
Hub to VSAT communication typically utilizes a broadcast mode protocol. In broadcast mode the hub sends out a single transmission which is received by the satellite and relayed to all of the terminals. The packets that are sent will include information identifying the intended recipient. All of the terminals will examine the identifying information and only the terminal that is the intended recipient will keep the message and pass it back up through the various protocol layers as provided for by the International Standards Organization's Open System Interconnect (ISO-OSI) 7-layer networking standard.
It is important to note in the satellite communications systems as just described, communication in the forward direction is a one-to-many communication and that there is no contention for access on the forward channel because there is only one transmitting entity. However, the return channel which has many remote terminals utilizing the return channel, contention, access and efficient use of the return channel or channels is a significant issue. As shown in the left hand portion of FIG. 1, Hub 105 can transmit on the forward channel to one or more VSAT's 110. As shown in the right hand portion of FIG. 1, one or more VSAT's can transmit on the reverse or return channel(s) to the Hub. An increase in the efficiency of utilization of the return channel can provide a major increase in the overall system throughput.
Because of the planetary physics involved, the orbits for geostationary satellites must be approximately 22,300 miles above the surface of the earth and the propagation delay for signals from the Hub to satellite to VSAT's (or vice versa) are all in the range of about 250 milliseconds. This delay is only the delay due to the radiofrequency propagation time and does not include any delay caused by other factors such as protocol overhead, packet collisions or packet retransmissions.
This propagation delay introduces significant complications when designing a network to efficiently transfer data in the shortest possible time. Because propagation times in hard-wired networks are relatively short, there are a number of design options to deal with transmission errors. One solution is to have the receiver send to the transmitter an acknowledgement packet (ACK) after the proper receipt of each packet. Because propagation times on wired or short range radio, network protocols such as Ethernet are essentially instantaneous, sending an ACK and a possible retransmission of each packet is a reasonable way to deal with missed packets. However, with propagation delays of at least 250 milliseconds, sending an ACK for each original packet sent would increase greatly the time needed to transfer each packet, as well as the whole message.
Multi-channel slotted Aloha (MCSA) networks are a standard method of implementing reverse satellite communications. MCSA is derived from the original ALOHAnet developed by Norman Abramson, working at the University of Hawaii. Abramson set up a packet radio network to connect terminals on the various Hawaiian Islands. Under the original protocol, there was a single outgoing frequency for broadcast communications from the hub to the remote terminals and a single, multi-access incoming frequency for communications from the remote terminals to the hub. Each remote terminal would transmit when it had data to send. If there were no collisions, i.e. simultaneous or partially overlapping transmissions, the terminal would receive a copy of that packet back from the hub on the broadcast frequency and know that its original outgoing transmission was successful. If no copy were received, this would be recognized as an error and the sending terminal would just send the packet again.
As used herein, the term “Aloha-type communications protocol” refers to a protocol having a forward channel one-to-many communications link (one hub to many terminals) and a reverse channel many-to-one communications link (same set of terminals communicating to the same hub).
A collision occurs when two or more remote terminals send their packets so that there is at least some overlap in the transmission of the two signals. For proper receipt of each packet, there needs to be only one remote terminal transmitting for the whole period of time that it takes for the one packet to be transmitted. If a second remote terminals starts to transmit at anytime during the transmission of the first terminal's packet, then the signals will overlap, collide and interfere with each other, and neither terminal's transmissions will be received correctly.
Each packet contains in internal error detection code, typically using a cyclic redundancy check (CRC), parity bit, or a checksum protocol. The hub will recalculate the values of these error detection protocols and compare them to the error detection bits that have been added to each packet. If the results are the same, then the packet is assumed to have been received correctly and it is then broadcast over the forward frequency to all of the remote terminals. If the error detection checking indicates that there was an error, then that indicates a collision between two or more packets.
If there were a collision, that would indicate that at least two terminals were attempting to transmit on the return frequency at the same time. In order to minimize the possibility of a second collision, each terminal waits a random period of time before attempting retransmission. This aids significantly in reducing collisions on retransmissions.
A modified version, called Slotted ALOHA, was introduced to increase efficiency. The hub would send out a timing pulse which created time slots. Any terminal that had data to send had to transmit within a predetermined period after receipt of the pulse. This modification increased efficiency by limiting the possibly for a collision to only the small scheduled period of time after the timing pulse.
The next expansion of the ALOHA protocol was a multi-channel slotted ALOHA (MCSA). This protocol includes multiple reverse channels for communication from the remote terminals to the hub.
These multiple channels can be accomplished by several means. Two of the most common methods are the spread spectrum technology methods of Direct Sequence Spread Spectrum (DS/SS) and Frequency Hopping Spread Spectrum (FHSS).
In addition, the reverse channels of MCSA can be implemented using series of narrowband channels each operating on separate frequency.
In either case, the addition of multiple channels to the ALOHA protocol, reduces the chance for collision by having more data paths available for original transmissions and retransmission of lost packets. Just like original transmissions, retransmissions use a random access contention access method to the reverse channels.
If we assume all the channels are operating at the same low load of G=0.1 and a message length equal to nine slots, the probability of success on the first transmission attempt is only 0.41. This means that only 41% of the messages can be delivered in the first try, i.e. with propagation delay of 250 ms. The remaining 59% of the messages will incur retransmissions and the message delay will be at least 750 ms (include the timeout period and another round trip propagation delay). Therefore in a GEO satellite network with a large propagation delay, the multi-channel slotted Aloha cannot deliver multi-slot short messages very quickly.